장애 상황에 대비하여 DB 인스턴스의 데이터베이스를 복구할 수 있도록 미리 준비할 수 있습니다 . 필요할 때마다 웹 콘솔에서 백업을 수행하거나, 주기적으로 백업이 수행되도록 설정할 수 있습니다. 백업이 수행되는 동안에는 해당 DB 인스턴스의 스토리지의 성능 저하가 발생할 수 있습니다. 서비스에 영향을 주지 않기 위해 서비스의 부하가 적은 시간에 백업할 것을 권장합니다. 백업으로 인한 성능 저하를 원치 않을 경우 고가용성 구성을 사용하거나 읽기 복제본에서 백업을 수행할 수도 있습니다.
[참고] 고가용성 DB 인스턴스는 예비 마스터에서 백업이 수행되어 마스터의 스토리지 성능 저하가 발생하지 않습니다.
RDS for MySQL에서는 Percona XtraBackup을 이용하여 데이터베이스를 백업합니다. 외부 MySQL의 백업으로 복원하거나 RDS for MySQL의 백업으로 복원하기 위해서는 RDS for MySQL에서 사용하는 Percona XtraBackup과 동일한 버전을 사용해야 합니다. DB 엔진 버전에 따른 Percona XtraBackup 버전은 아래와 같습니다.
| MySQL 버전 | XtraBackup 버전 |
|---|---|
| 5.7.15 | 2.4.28 |
| 5.7.19 | 2.4.28 |
| 5.7.26 | 2.4.28 |
| 5.7.33 | 2.4.28 |
| 5.7.37 | 2.4.28 |
| 8.0.18 | 8.0.32 |
| 8.0.23 | 8.0.32 |
| 8.0.28 | 8.0.32 |
| 8.0.32 | 8.0.32 |
| 8.0.33 | 8.0.33 |
| 8.0.34 | 8.0.34 |
| 8.0.35 | 8.0.35 |
[참고] 2023년 8월 17일 XtraBackup 유틸리티의 버전이 업그레이드되었습니다. 이전 백업에 사용된 XtraBackup 버전은 웹 콘솔에서 확인할 수 있습니다. 고가용성 DB 인스턴스는 예비 마스터에서 백업이 수행되어 마스터의 데이터 스토리지 성능 저하가 발생하지 않습니다.
백업 시에 적용되는 설정 항목은 다음과 같으며, 자동 백업 및 수동 백업 시에 모두 적용됩니다.
테이블 잠금 사용
FLUSH TABLES WITH READ LOCK 구문의 실행 여부를 설정합니다.FLUSH TABLES WITH READ LOCK 구문을 실행합니다. FLUSH TABLES WITH READ LOCK 구문의 실행에 실패할 경우 백업에 실패하게 됩니다.FLUSH TABLES WITH READ LOCK 구문을 실행하지 않기 때문에 DML 부하가 많아도 백업이 실패하지 않습니다. 하지만 테이블 잠금을 사용하지 않은 백업은 백업 데이터의 일관성이 보장되지 않을 수 있으며, 이에 따라 테이블 잠금을 사용하지 않고 생성된 백업 및 테이블 잠금을 사용하지 않도록 설정된 DB 인스턴스에 대해 복원 및 복제 과정을 포함한 일부 작업을 지원하지 않습니다.쿼리 지연 대기 시간(초)
FLUSH TABLES WITH READ LOCK 구문의 대기 시간을 설정합니다. 쿼리 지연 대기 시간만큼 FLUSH TABLES WITH READ LOCK 구문이 대기하게 됩니다. 0~21,600초까지 설정 가능합니다. 길게 설정할 수록 DML 쿼리 부하로 인한 백업 실패 가능성을 줄일 수 있으나, 전체 백업 시간이 길어질 수 있습니다.특정 시점의 데이터베이스를 영구히 저장하려면 웹 콘솔에서 수동으로 백업을 수행할 수 있습니다. 수동 백업은 자동 백업과 달리 명시적으로 백업을 삭제하지 않는 한 DB 인스턴스가 삭제될 때 같이 삭제되지 않습니다. 수동 백업 시 백업의 이름을 입력해야 하며 아래와 같은 제약 사항이 있습니다.
수동으로 백업을 수행하는 경우 외에도 복원 작업을 위해 필요한 경우 또는 자동 백업 스케줄 설정에 따라 자동 백업이 수행될 수 있습니다. 자동 백업은 DB 인스턴스와 생명 주기가 동일합니다. DB 인스턴스가 삭제되면 보관된 자동 백업은 모두 삭제됩니다. 자동 백업에서 지원하는 설정 항목은 아래와 같습니다.
자동 백업 허용
자동 백업 보관 기간
자동 백업 복제 리전
자동 백업 재시도 횟수
자동 백업 스케줄 사용
자동 백업 수행 시간
자동 백업의 이름은 {DB 인스턴스의 이름}_yyyy-MM-dd-HH-mm 형태로 부여됩니다.
[주의] 앞선 백업이 종료되지 않는 등의 상황에서는 백업이 수행되지 않을 수 있습니다.
모든 백업 파일은 내부 백업 스토리지에 업로드하여 저장합니다. 수동 백업의 경우 별도로 삭제하기 전까지 영구히 저장되며 백업 용량에 따라 백업 스토리지 과금이 발생합니다. 자동 백업의 경우 설정한 보관 기간만큼 저장되며 자동 백업 파일의 전체 크기 중 DB 인스턴스의 스토리지 크기를 초과한 용량에 대해서 과금합니다. 백업 파일이 저장된 내부 백업 스토리지에 직접 접근할 수 없으며, 백업 파일이 필요한 경우 NHN Cloud의 오브젝트 스토리지로 백업 파일을 내보낼 수 있습니다.
내부 백업 스토리지에 저장된 백업 파일을 NHN Cloud의 사용자 오브젝트 스토리지로 내보낼 수 있습니다. 수동 백업 혹은 자동 백업 파일을 내보내거나, 백업을 수행함과 동시에 백업 파일을 사용자 오브젝트 스토리지로 내보낼 수 도 있습니다. 백업을 내보내는 동안 원본 DB 인스턴스의 네트워크 성능 하락이 발생할 수 있습니다.
[참고] 수동 백업의 경우 백업을 수행한 원본 DB 인스턴스가 삭제되었다면 백업을 내보낼 수 없습니다.
백업을 이용하여 원하는 시점으로 데이터를 복원할 수 있습니다. 복원 시 항상 새로운 DB 인스턴스가 생성되며, 기존 DB 인스턴스에 복원할 수 없습니다. 백업을 수행한 원본 DB 인스턴스와 동일한 DB 엔진 버전으로만 복원할 수 있습니다. 백업이 생성된 시점으로 복원하는 스냅숏 복원, 원하는 특정 시점으로 복원하는 시점 복원을 지원합니다. RDS for MySQL에서 생성한 백업뿐만 아니라 외부 MySQL의 백업으로도 복원할 수 있습니다.
[주의] 복원할 DB 인스턴스의 데이터 스토리지 크기가 백업을 수행한 원본 DB 인스턴스의 데이터 스토리지 크기보다 작거나, 원본 DB 인스턴스의 파라미터 그룹과 다른 파라미터 그룹을 사용할 경우 복원에 실패할 수 있습니다.
스냅샷 복원은 백업을 수행한 시점으로 복원합니다. 백업 파일만으로 복원을 진행하여, 백업을 수행한 원본 DB 인스턴스가 필요하지 않습니다.
시점 복원을 이용하여 원하는 특정 시점 또는 바이너리 로그(binary log)의 특정 포지션으로 복원할 수 있습니다. 시점 복원을 하기 위해서는 백업 파일과 백업을 수행한 시점으로부터 복원을 원하는 시점까지의 바이너리 로그(binary log)가 필요합니다. 바이너리 로그(binary log)는 백업이 수행되는 원본 DB 인스턴스의 스토리지에 저장됩니다. 바이너리 로그(binary log) 보관 기간이 짧으면 스토리지 용량을 더 많이 사용할 수 있지만, 원하는 시점으로 복원이 어려울 수 있습니다. 아래 나열된 경우 시점 복원에 필요한 바이너리 로그(binary log)가 없기 때문에 원하는 시점으로 복원하지 못할 수 있습니다.
외부 MySQL 백업 파일을 이용하여 DB 인스턴스를 생성할 수 있습니다. 외부 MySQL 백업 파일을 생성할 때 백업 항목을 참고하여 RDS for MySQL에서 사용하는 Percona XtraBackup과 동일한 버전을 사용해야 합니다.
[주의] innodb_data_file_path의 설정값이 ibdata1:12M:autoextend가 아니면 RDS for MySQL의 DB 인스턴스로 복원할 수 없습니다.
(1) MySQL이 설치된 서버에서 아래의 명령어를 이용하여 백업을 수행합니다.
XtraBackup 2.4.xx 예제
innobackupex --defaults-file={my.cnf 경로} --user {사용자} --password '{비밀번호}' --socket {MySQL 소켓 파일 경로} --compress --compress-threads=1 --stream=xbstream {백업 파일이 생성될 디렉터리} 2>>{백업 로그 파일 경로} > {백업 파일 경로}
XtraBackup 8.0.xx 예제
xtrabackup --defaults-file={my.cnf 경로} --user={사용자} --password='{비밀번호}' --socket={MySQL 소켓 파일 경로} --compress --compress-threads=1 --stream=xbstream --backup {백업 파일이 생성될 디렉터리} 2>>{백업 로그 파일 경로} > {백업 파일 경로}
(2) 백업 로그 파일의 마지막 줄에 completed OK!가 있는지 확인합니다. completed OK!가 없다면 백업이 정상적으로 종료되지 않은 것이므로 로그 파일에 있는 에러 메시지를 참고하여 백업을 다시 진행합니다.
(3) 완료된 백업 파일을 오브젝트 스토리지에 업로드합니다.
(4) 복원할 프로젝트의 웹 콘솔에 접속한 뒤 DB 인스턴스 탭에서 오브젝트 스토리지에 있는 백업으로 복원 버튼을 클릭합니다.
[주의] 현재 5.7.33 버전에서는 오브젝트 스토리지의 백업 파일을 이용한 DB 인스턴스 복원은 제한됩니다. 권장하는 XtraBackup 이외의 버전을 사용하면 정상으로 동작하지 않을 수 있습니다. 오브젝트 스토리지의 백업 파일과 복원하려는 MySQL의 버전은 동일해야 합니다.
RDS for MySQL의 백업 파일을 이용하여 직접 MySQL의 데이터베이스를 복원할 수 있습니다. RDS for MySQL 백업 파일을 복원할 때 백업 항목을 참고하여 RDS for MySQL에서 사용하는 Percona XtraBackup과 동일한 버전을 사용해야 합니다.
(1) 백업 내보내기 항목을 참고하여 RDS for MySQL의 백업을 오브젝트 스토리지로 내보냅니다.
(2) 오브젝트 스토리지의 백업을 복원하고자 하는 서버에 다운로드합니다.
(3) MySQL 서비스를 정지합니다.
(4) MySQL 데이터 저장 경로의 모든 파일을 삭제합니다.
rm -rf {MySQL 데이터 저장 경로}/*
(5) 다운로드한 백업 파일의 압축을 해제하고 복원합니다.
XtraBackup 2.4.xx 예제
cat {백업 파일 저장 경로} | xbstream -x -C {MySQL 데이터 저장 경로}
innobackupex --decompress {MySQL 데이터 저장 경로}
innobackupex --defaults-file={my.cnf 경로} --apply-log {MySQL 데이터 저장 경로}
XtraBackup 8.0.xx 예제
cat {백업 파일 저장 경로} | xbstream -x -C {MySQL 데이터 저장 경로}
xtrabackup --decompress --target-dir={MySQL 데이터 저장 경로}
xtrabackup --prepare --target-dir={MySQL 데이터 저장 경로}
xtrabackup --defaults-file={my.cnf 경로} --copy-back --target-dir={MySQL 데이터 저장 경로}
(6) 압축 해제 후 불필요한 파일을 제거합니다.
find {MySQL 데이터 저장 경로} -name "*.qp" -print0 | xargs -0 rm
(7) MySQL 서비스를 시작합니다.